Modern software typically involves many components often developed by large teams of software developers. The days of procedural programming in which a single developer could write an application that simply executed from start to finish performing a single, well-defined task are gone. A software developer often uses libraries, components, frameworks, and other bodies of code written by other developers. The chances for mistakes or misunderstanding how to use a particular external function or module are higher than ever.
One verification method for increasing the correctness of software is called unit testing. When unit testing, a software developer attempts to isolate a particular unit of the software from external influences in a way that the unit can be tested in isolation. In theory, if each unit of a software application is correct, then the only room left for error is in communication between components, so unit testing can dramatically reduce software error rates. Unit tests often replace externally invoked libraries or components written by other developers with stubs or replacement objects that mimic the functionality of an external component but feed directed responses into the unit under test to test the unit's reaction to particular return values, operating conditions, and so forth.
When writing a unit test that invokes methods on objects where the method pointers are determined at compile-time (i.e., non-virtual or static), there is currently no way to redirect or “mock” these method calls so that they invoke fake methods instead. This makes it very difficult to test methods that call other methods that are non-virtual, because it is not possible to redirect these method calls without recompiling them so that they can be redirected at runtime. Existing solutions to this problem dynamically generate subclasses of classes a developer wants to mock and inject the generated subclasses into the class the developer wants to test. This method exploits polymorphism so that the invoked methods are determined at runtime, but the method only works if the base class methods are declared virtual. Another cumbersome solution is to use the Common Language Runtime (CLR) profiler application-programming interface (API), which attaches to the MICROSOFT™.NET runtime to intercept all method calls.